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TRACING THE EXECUTION PATH OP A COMPUTER PROGRAM 

The present invention relates to tracing, and more particularly to 
tracing the execution path of a computer program. 

5 

Computers have proliferated into all aspects of society and 
increasingly form the backbone of large organisations . When a computer 
system fails to respond as intended, businesses are invariably unable to 
provide even the most basic of services. Money, reputation or even lives 
10 may be lost, dependant upon- the critical! ty of the service, the outage time 

etc . 

In today's increasingly competitive marketplace, quality is of the 
utmost concern. Users' expectations are high and thus the reliability of 
15^ hardware /software is especially important. Customers do not tolerate 

mistakes and the later a defect is discovered, the more costly it can prove 
to the manufacturer. 

Typically therefore, software developers implement a rigorous testing 

2 0 regime in order to ensure that a product or system is fully operational and 

consistently performs according to its functional specification, before it 
is made available to the public. 

Software development is however an increasingly complex process. 
25 Even using the most rigorous techniques, software developed by people will 

suffer failures. Most software developers understand this and therefore 
accept the need to be able to effectively diagnose the cause of such a 
software failure. 

3 0 A most effective technique is known as "tracing" . In this technique 

a program records ("traces") important information that can be used for 
further analysis after the occurrence of a software failure. Figure 1 is a 
component diagram of a computer system performing tracing according to the 
prior art. A computer system 10, runs an operating system (o/s) 20, which 

3 5 could for example be Windows NT available from Microsoft Corporation. A 

program 3 0 executes on top of operating system 2 0 and may consist of a 
number of separate modules (not shown) , each defining separate 
functionality. As program 3 0 executes, it calls various trace functions 4 0 
which are used to record certain information in a trace log 50. Note, 

4 0 although the log is shown as present on the same computer system, computer 
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system 10 may in fact be connected to another machine across a network 
(neither shown) and the trace log may instead reside on that machine. 

Tracing typically occurs at three stages in the processing or 
executing of a program. These stages are known as the "entry", "exit" and 
"exception" points of tracing. 

The "entry" trace information is gathered when a module obtains 
control from another module. The information recorded is normally the 
input values provided to the module. 

The "exit" trace information is gathered when a module returns 
control to a module from which it has previously received control. The 
information recorded is normally the output values returned to the module 
from which it obtained control in the first place. 

The "exception" trace information is gathered whenever an 
extraordinary or interesting event occurs within a module after it has been 
entered but before it has returned control to the module from whom it 
originally received control. The information gathered is normally 
information that relates to the exceptional condition that has occurred. 

As previously mentioned the entry, exit and exception information is 
outputted to a trace log. Upon the occurrence of a software failure, a 
software developer can analyse the trace information in this log. This 
information can then be used to determine which modules were called and 
what information was passed between them, including any interesting events 
that have occurred. This hopefully allows the developer to understand and 
locate the source of the error and fix it. 

Figure 2 shows entry, exit and exception tracing according to the 
prior art. A program 100 consists of two modules, "Main" 105 and 
"Function" 110. The program runs on an operating system 120 which 
initially passes control to Main. Main receives two parameters, pi and p2 
as input. These may be specified by the user from the command-line or be 
the result of output from another program / module (not shown) . Main calls 
a trace_in function to record entry trace to trace log 130, and a trace_out 
function to record exit trace to trace log 13 0. 

Trace_in is passed three parameters, "Main", pi, and p2 . "Main" is 
used as an identifier in the trace log such that the values of pi and p2 



GB000078GB1 



3 



can be connected with module Main. It can be seen from the log that 
parameters pi and p2 have values of 1 and 3 respectively upon entry to 
Main. Control is then passed to module FUNCTION 110, which passes 
parameters p3 and p4 as parameters. FUNCTION performs a trace_in on both 
p3 and p4, which are identified by the heading "FUNCTION" in trace log 130. 
It can be seen that p3 has a value of 2 and p4 has a value of 4 upon entry 
to the module FUNCTION. 

A trace_data function writes extraordinary events / events of 
interest to the trace log. It passes an identifier "FUNCTION" and the data 
to be read out DATA1, or a number of parameters. This is exception trace. 

Module FUNCTION ends and a trace_out function is called passing it 
the "FUNCTION" identifier, along with parameters p3 and p4 . Note, the 
dotted lines connecting the various trace functions represent calculations 
and processing performed by the program but not shown (i.e. additional 
program instructions) . It can be seen from trace log 13 0 that such program 
instructions have manipulated p3 and p4 such that their values have changed 
from those initially recorded at trace_in. P3 now equals 5 and p4 equals 
2 . 

As previously mentioned, exit information (via the trace_out 
function) is recorded prior to a module relinquishing control to the module 
which originally called it. In this example control is returned to Main 
10 5, additional processing performed (dotted lines) and the trace__out 
function called. It is passed the "Main" identifier, along with pi and p2 . 
The trace log once again shows that additional program instructions have 
manipulated pi and p2 such that their values are now 4 and 1 respectively. 
Control is then returned to operating system 120. 

Tracing, typically occurring at entry, exit and exception, has a very 
coarse granularity. It provides very little information as to the path 
followed during program execution. It is possible to obtain a reasonable 
level of detail by calling the trace_data function on a regular basis (or 
whenever anything unusual happens (e.g. the value of a particular parameter 
is not as expected)), but this is expensive in terms of CPU time. Even on 
the OS/390 systems (available from IBM Corporation) , in which trace 
information is dumped to fast volatile memory, performance is degraded by 
approximately 50%. For this reason customers often cannot afford to leave 
trace running continuously. Thus when a software failure occurs, the 
operating system often provides call hierarchy (i.e. which modules were 
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called during program execution) but does not provide any more information 
than that. Time is lost because, trace then has to be turned on and the 
failure simulated before diagnostics can begin. Customers do not expect 
these sort of delays. In their eyes, software that they've paid good money 
5 for is not supposed to fail. 



Not only is tracing expensive in terms of CPU performance, but 
hand- instrumenting a program with trace instructions is a time consuming 
job. Knowing the most appropriate points at which to place trace_data 
10 statements also requires experience. Trace^in and trace__ out statements, on 

the other hand, always go at the beginning and end of a module 
respectively . 

Even when all the appropriate trace information is captured in a 
15 trace log, this information can be difficult to extract. When a module 

completes, it is only possible to determine which processing occurred 
within the module by searching for the previous entry trace for that module 
and examining all the trace entries that this module may have called. This 
is exceptionally tedious, especially if the flow of control through modules 
2 0 is complex. The situation may be further complicated in a multi-user 

system where trace records for multiple activities are traced at the same 
time . 



Figure 3 shows tracing in a multi-user system according to the prior 
25 art. A computer system (not shown) runs a Process 1. This includes three 

program modules A, B and C, each with trace__in and trace_out function 
calls. Trace Log 150 shows the trace information outputted by process 1. 
It can be seen that trace_in (ti) is called for all modules. Trace_out 
(to) is then called for module C. Note, although not shown, the log will 
3 0 in reality contain parameter values for each trace function call (see 

figure 2 ) . 



Before trace_out can be called for modules B and A (in that order) , 
process 2 is started. Process 2 also includes three modules, A, B and C, 

35 each calling the trace_in and trace_out functions. Thus process 2 dumps 

the trace_in parameter values for module A out to log 150. This entry 
fills up the log. New information is thus written to the beginning of the 
log (shown by the circular arrows) . Trace Log 150' shows what happens 
next. Process 2 runs faster than process 1 and thus it continues to write 

4 0 to the trace log 15 0* from the top. Process 2 thus outputs trace_in 

information for its module B, and C. It also dumps trace_out information 
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for its modules C and B. Obviously both processes have not finished 
outputting information to the trace log 150 * , but it can be seen that at 
this point in time all the trace information above the dotted line in trace 
log 150 for process 1, has been overwritten by process 2. Thus in. the 
event of a software failure, log 150' provides very little help in 
diagnosing the execution flow taken by process 1. Note, Processes 1 and 2 
may be on the same machine or on separate machines. 

Accordingly, the invention provides a method for tracing the 
execution path of a computer program comprising at least one module 
including a plurality of instructions, at least one of said instructions 
being a branch instruction, the method comprising the steps of: 
identifying each branch instruction; evaluating each branch instruction to 
be one of true and false; and responsive to an evaluation of true, pushing 
a unique identifier into a predefined area of storage, wherein said unique 
identifier is associated with the instructions executed as a result of said 
evaluation of true. 

Preferably, the storage area is in volatile memory and the contents 
of the storage area is output to non- volatile memory (e.g. a file or trace 
log) at a predetermined point in time. Alternatively, the storage area 
itself is non- volatile memory. 

In the preferred embodiment trace information is output to the trace 
log upon exit from the at least one module and the contents of the storage 
area is output at the same time. Thus the log contains a record of the 
values of any specified parameters upon exit from the at least one module, 
as well as a record of the execution path taken through that module. 

Since the exit record is the most recent trace record to be written, 
it is preferably possible to determine the flow through the module even if 
this is the only trace record available (i.e. the only record that has not 
been overwritten) . Thus the problem addressed with reference to figure 3 is 
addressed. Furthermore, because the contents of the storage area is 
preferably output ted as one record, it is easy to extract the information 
from the trace log. The trace log may consist of multiple trace entries 
interwoven with trace entries from other systems. According to the 
preferred embodiment, one can easily extract the relevant entry as all the 
information is held on the one line. 
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Alternatively, the contents of the storage area is output to the log 
when the storage area is determined to be full . As yet another 
alternative, the contents of the storage area is output to the log upon the 
occurrence of a failure within the program. 

In all cases customer satisfaction is increased because the 
information contained within the storage area can be used to diagnose 
problems more quickly. The information provides a much greater level of 
detail than previously possible. It indicates the execution path or flow 
followed through a program and is especially useful when the program being 
traced is complex. It provides a valuable insight into the behaviour of 
the program at run-time. 

According to the preferred embodiment, the cost of pushing a unique 
identifier into the storage area upon execution of a particular set of 
program instructions is trivial. Thus customers can afford to run with 
trace on continuously so that important problem diagnostics information can 
be collected in real-time. 

Preferably, when the last- available space in the storage area has 
been written, old identifiers are overwritten from the beginning of the 
area with new values. Thus the storage area can be of a limited size and 
does not consume an unnecessary amount of resources. A sensible size for 
the storage area depends upon the complexity of the program being traced. 

According to the preferred embodiment, the storage area stores the 
position at which the last unique identifier was written. Thus it is 
possible to determine the number of unique identifiers that have been 
overwritten in the circular storage area, before being outputted to the 
trace log. If this number is excessively large, the size of the storage 
area is preferably increased. 

In a further aspect, the invention provides an apparatus for tracing 
the execution path of a computer program comprising at least one module 
including a plurality of instructions, at least one of said instructions 
being a branch instruction, said apparatus comprising: means for 
identifying each branch instruction; means for evaluating each branch 
instruction to be one of true and false; and means, responsive to an 
evaluation of true, for pushing a unique identifier into a predefined area 
of storage, wherein said unique identifier is associated with the 
instructions executed as a result of said evaluation of true . 
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In a yet still further aspect, the invention provides a method for 
instrumenting a computer program comprising at least one module including a 
plurality of instructions, at least one of said instructions being a branch 
instruction, each branch instruction being evaluated to be one of true and 
false at run- time, with at least one signature instruction for indicating 
the execution path of said program at run- time, the method comprising the 
steps of: identifying each branch instruction; identifying the 
instructions associated with an evaluation of true at run- time; 
instrumenting said instructions associated with an evaluation of true with 
a signature instruction, wherein said signature instruction causes a unique 
identifier to be pushed into a predefined area of storage upon execution of 
said true instructions at run-time. 

According to the preferred embodiment, little experience is required 
to hand- instrument the code, since such signature instructions are always 
associated with a branch instruction. This is unlike the placing of 
trace_data statements, which do require more experience. Preferably, it is 
only as a result of a branch instruction that the execution flow changes. 
Otherwise, each instruction is executed on a line by line basis. 

According to another aspect, the invention provides a compiler for 
instrumenting a computer program comprising at least one module including a 
plurality of instructions, at least one of said instructions being a branch 
instruction, each branch instruction being evaluated to be one of true and 
false at run- time, with at least one signature instruction for indicating 
the execution path of said program at run- time, said compiler comprising: 
means for identifying each branch instruction; means for identifying the 
instructions associated with an evaluation of true at run- time; means for 
instrumenting said instructions associated with an evaluation of true with 
a signature instruction, wherein said signature instruction causes a unique 
identifier to be pushed into a predefined area of storage upon execution of 
said true instructions at run-time. 

According to the preferred embodiment, automatically instrumenting a 
program with signature instructions greatly eases the job of the software 
developer. Detailed program execution flow can be obtained, without the 
time consuming task of modifying the code by hand. 

A preferred embodiment of the present invention will now be 
described, by way of example only, and with reference to the following 
drawings : 
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Figure 1 is a component diagram of a computer system performing 
tracing according to the prior art; 

Figure 2 shows entry, exit and exception tracing according to the 
5 prior art; 

Figure 3 shows tracing in a multi-user system according to the prior 
art ; and 

10 Figures 4 and 5 illustrate tracing according to a preferred 

embodiment of the present invention. 

Figure 6 shows the process of outputting signature information at the 
first point of failure according to a preferred embodiment of the present 
15 invention; and 

Figure 7 shows the operation of a compiler in accordance with a 
preferred embodiment of the present invention. 

2 0 Figures 4 and 5 should be- read in conjunction with one another. 

Figure 5 shows a sample program, "test program", from which execution 
information is gathered at run- time according to a preferred embodiment of 
the present invention. Figure 4 is a flow chart illustrating how the 
sample program executes in accordance with the preferred embodiment. 

25 

Upon execution of the program, a small, fixed size area called a 
signature area 300 is defined (step 200) . In the example, the signature 
area may contain up to eight signature points 310 (define sig_area 
size (8)) . Each signature point comprises a unique 4 bit identifier 

3 0 (number) . This identifier is, according to the preferred embodiment, used 

to indicate the execution path or flow followed through the program. 

Typically a program executes each instruction line by line, until a 
decision point or branch instruction is reached. It is at such a point 
3 5 that the program may jump to a specified piece of code (set of 

instructions) or else ignore that code and continue with subsequent 
instructions. One example of a branch instruction is an "if statement" 
(found in most programming languages) : 



40 
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if condition = TRUE 




do 




instruction 


1; 


instruction 


2; 


end do; 




else 




do 




instruction 


3; 


end do; 




end if ; 





It can be seen from the above that either instructions 1 and 2 are 
executed, or instruction 3 alone, dependant upon whether 11 condition" = TRUE 
5 or FALSE. There are many other examples of branch instructions (e.g. case 

tests / statements found in the C programming language) and it is at such 
points that it is helpful to capture execution flow information. The 
signature area 3 00 holds this information. 



10 At step 210 of figure 4, the signature area is initialised to 0 (set 

sig_area=0) (not shown in figure 5) . In this example, the trace_in 
function is called as before (step 220) , although this does not have to be 
so. Note, trace_in is passed one or more parameters as previously 
explained (not shown in figure 5) . 

15 

In the example, the program then loops until a condition evaluates to 
TRUE (step 230) , at which point the program calls the trace_out function 
(step 280) . This function also accepts parameters as previously discussed 
(not shown) . Whilst however the condition evaluates to FALSE , the logic 

20 between "repeat until..." and "end repeat" is performed. In the example, 

this logic consists of a number of case statements (branch instructions) . 
A case statement is a Boolean test. In the example, the first case 
statement evaluates to TRUE when a parameter (not shown) = 1, the second 
case statement evaluates to TRUE when another parameter (not shown) = 2, 

2 5 and so on. An evaluation of TRUE results in the code forming part of the 

current case statement being executed, otherwise the next case statement is 
evaluated. Thus it will be appreciated that the execution flow through the 
program will vary dependant upon the evaluation of each case statement. 



30 



Thus in accordance with figure 4, a case statement is evaluated (step 
230) . If it evaluates to FALSE, then step 270 checks for another case 
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statement. If there aren't any, then step 230 evaluates the original 
condition. The program then either loops round again or outputs trace at 
step 2 80. 

5 If on the other hand, a case statement evaluates to TRUE at step 240, 

then an identifier is pushed into the signature area at step 250 (e.g. push 
1 into sig_area) . Although in the example, this identifier is hard-coded, 
this need not be the case. The hard-coded numeral may, for example, be 
replaced with a variable, initially set to 0 and then incremented each time 
10 a push into the signature area is made. A pointer 320 keeps note of the 

current position in the signature area. Having pushed a unique identifier 
into this signature area, the pointer is incremented at step 260. 

According to the preferred embodiment, signature points are added 
15 into the signature area from left to right (Note, this does not have to be 

the case and other variations are considered within the spirit of the 
invention) . In the example, the seven most recent signature points are 
held in the signature area. These are used to track the execution flow 
through the program. The purpose of the last element 330 will be explained 
2 0 later. 



In the example, case statement 1 is evaluated to TRUE first such that 
1 is pushed into the signature area. Execution then jumps to case 
statement 4 (i.e. case statements 2 and 3 evaluate to false) (arrow 1); case 

2 5 statement 2 (arrow 2) ; case statement 3 (arrow 3) ; case statement 1 (arrow 

4) ; and finally case statement 2 (arrow 5) . It can be seen that the 
corresponding identifiers have been pushed into the signature area (1; 4; 
2; 3; 1; 2). These numbers indicate which set of instructions have been 
executed at run- time and in what order. 

30 

According to the preferred embodiment, when the program or module 
finishes, trace is output to trace log 340 as before (step 280) . 
Additionally the information contained within the signature area is also 
output to the trace log (step 2 90) . The signature information provides 

3 5 valuable insight into the behaviour of the program. Should the program 

fail or behave erroneously, then the signature points can be used in 
subsequent problem diagnostics . 



40 



According to the preferred embodiment, once the signature area 3 00 is 
full, old signature points are overwritten. Note, according to the 
preferred embodiment signature information is only written out to the trace 
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log along with a trace exit record (i.e. at the end of the module /program) . 
If a module/program is particularly complex, then the signature area may 
not be large enough. Thus signature points may be overwritten before they 
are recorded in the trace log. The last element 330 holds the number of 
the last signature point that is written (6). It is possible to determine 
from this number how much signature information is missing as a result of 
being overwritten. For example, if a signature point is written into 
element 7, this fills the signature area. A subsequent signature point is 
thus written into the first element of the signature area. Last element 
330 is then updated to read 1. It is thus possible to determine that the 
first element in the signature area has been overwritten before being 
outputted to the trace log (i.e. it is possible to determine that this 
information is missing) . If a large number of signature points are 
continually overwritten before being recorded in the trace log, then a 
larger signature area can be defined. In an alternative embodiment, the 
signature information is written straight out to the trace log every time 
the signature area is filled. 

For many modules it is sufficient to have a small number (e.g. 15) of 
signature points and a signature area limited to 3 2 bits (i.e. 4 bits per 
signature point, making 8 signature points) . The push operation usually 
becomes two low- level instructions (a SHIFT followed by an OR) . Therefore, 
for all practical purposes, the implementation cost is negligible. Even 
for larger signature areas and more signature points, a trivial marginal 
processing overhead is required. Thus a simple and efficient determination 
of module processing is provided. As a result, customers can afford to run 
with a more detailed trace (i.e. than that provided by the trace_in and 
trace_out functions) on continuously. 

As previously mentioned, according to the preferred embodiment, the 
signature information is always written out with the exit trace record 
(i.e. the trace_out data). Since the exit trace record is the most recent 
trace record to be written, it is possible to determine the flow through 
the module even if this is the only trace record available (i.e. the only 
record that has not been overwritten) . Thus the problem discussed with 
reference to figure 3 is addressed. 

In an alternative embodiment, the signature information is outputted 
to the trace log at the point of failure (see figure 6) . This is useful in 
the situation where a failure causes the program/module to loop 
indefinitely and thus never output that extremely helpful exit record. 
Furthermore, customer satisfaction is increased since problems can be 
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diagnosed much more quickly. There is no need to instrument the program 
with the more detailed trace_data statements, which takes time and 
experience. Instead data is captured upon a first failure and technicians 
can set about solving the problem immediately. Of course outputting the 
signature information also increases customer satisfaction because it too 
decreases the time taken to solve a software failure. 

In one embodiment a program's code is hand- instrumented with 
instructions that enable a signature point to be pushed into the signature 
area. Note, as previously mentioned, such signature points are preferably 
only required at points where the code branches. Thus less experience is 
needed to determine where to place the signature points. This is unlike 
the placing of the trace_data statements, which do require more experience. 
According to an alternative embodiment, the code is automatically 
instrumented with such instructions at compile- time . 

Figure 7 shows the operation of a compiler in accordance with a 
preferred embodiment of the present invention. A compiler 410 is provided 
with a program's source code 400 as input. The compiler processes this 
source code to produce object code 420. A listing of the source code 415 
can also be produced at this stage. The object code is then passed to a 
linker 430 which uses this code 420 to produce an executable 440. 

Typically, there are three stages to the compilation process: 
lexical analysis; syntax analysis; and code generation. During the lexical 
analysis, symbols (e.g. alphabetic characters) are grouped together to form 
tokens. For example the characters PRINT are grouped to form the 
command (token) PRINT. In some systems, certain key words are replaced by 
shorter, more efficient tokens. This part of the compilation process also 
verifies that the tokens are valid. Next, the syntax analyser checks 
whether each string of tokens forms a valid sentence. Finally, the code 
generation stage produces the appropriate object code. 

The syntax analyser is able to identify branch instructions in a 
program's source code. According to the alternative embodiment, the 
compiler is modified to instrument the code with instructions for pushing a 
signature point into a defined signature area after each occurrence of a 
branch instruction. By allowing the compiler to automatically instrument 
the code at compile- time , the job of the software developer is greatly 
eased. Detailed execution flow information can be obtained, without the 
time consuming task of modifying the code by hand. Preferably, the 
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compiler also instruments the code with an instruction to define the size 
of the signature area and an instruction to write the signature information 
out to a trace log at the appropriate point (any one of those discussed 
above) . 

According to the alternative embodiment, source code is compiled with 
one or both of two compiler switches set. The first switch determines 
whether the code is automatically instrumented with signature points or 
not, and the second switch allows a user to modify the size of the 
signature area. If the program being traced is particularly complex, then 
the size of the signature area may need to be increased. 
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CLAIMS 

1. A method for tracing the execution path of a computer program 
comprising at least one module including a plurality of instructions, at 
least one of said instructions being a branch instruction, the method 
comprising the steps of : 

identifying each branch instruction; 

evaluating each branch instruction to be one of true and false; and 

responsive to an evaluation of true, pushing a unique identifier into 
a predefined area of storage, wherein said unique identifier is associated 
with the instructions executed as a result of said evaluation of true. 

2. The method of claim 1, wherein said predefined area of storage is in 
volatile memory. 

3. The method of claim 1, wherein said predefined area of storage is in 
non- volatile memory. 

4. The method of claim 1 or 2 , comprising the step of: 

outputting the contents of said storage area to a file at a 
predetermined point in time. 

5 . The method of claim 4 , comprising the step of : 

outputting trace information to said file upon exit from said at 
least one module, 

6. The method of claim 5, wherein the contents of said storage area is 
outputted at the same time as said exit trace information. 

7. The method of claim 4, wherein the step of outputting the contents of 
said storage area comprises: 

determining whether said storage area is full; and 

responsive to a positive determination, outputting said contents to 
said file. 
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8. The method of claim 4, wherein the step of outputting the contents of 
said storage area comprises : 

determining whether a failure has occurred within said program; and 

5 responsive to a positive determination, outputting said contents to 

said file. 

9 . The method of any of claims 4 to 8 , wherein the step of pushing a 
unique identifier into a predefined area of storage further comprises the 

10 steps of: 

determining whether said predefined area of storage is full; and 
overwriting the first unique identifier in said storage area; and 

10. The method of claim 9, comprising the step of: 

writing the position of the most recent unique identifier to be 
written out to said storage area to said storage area. 

11. The method of claim 10, wherein said position is used to determine 
the number of unique identifiers that have been overwritten prior to being 
written out to said file. 

25 12. The method of claim 11, comprising the step of: 

responsive to determining that a large number of unique identifiers 
have been overwritten, increasing the size of said predefined area of 
storage . 
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13 . An apparatus for tracing the execution path of a computer program 
comprising at least one module including a plurality of instructions, at 
least one of said instructions being a branch instruction, said apparatus 
comprising : 

means for identifying each branch instruction; 

means for evaluating each branch instruction to be one of true and 
false; and 
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means, responsive to an evaluation of true, for pushing a unique 
identifier into a predefined area of storage, wherein said unique 
identifier is associated with the instructions executed as a result of said 
evaluation of true. 

14 . A method for instrumenting a computer program comprising at least one 
module including a plurality of instructions, at least one of said 
instructions being a branch instruction, each branch instruction being 
evaluated to be one of true and false at run- time, with at least one 
signature instruction for indicating the execution path of said program at 
run-time, the method comprising the steps of: 

identifying each branch instruction; 

identifying the instructions associated with an evaluation of true at 
run- time ; 

instrumenting said instructions associated with an evaluation of true 
with a signature instruction, wherein said signature instruction causes a 
unique identifier to be pushed into a predefined area of storage upon 
execution of said true instructions at run-time . 

15. A compiler 'for instrumenting a computer program comprising at least 
one module including a plurality of instructions, at least one of said 
instructions being a branch instruction, each branch instruction being 
evaluated to be one of true and false at run- time, with at least one 
signature instruction for indicating the execution path of said program at 
run- time, said compiler comprising: 

means for identifying each branch instruction; 

means for .identifying the instructions associated with an evaluation 
of true at run-time ; 

means for instrumenting said instructions associated with an 
evaluation of true with a signature instruction, wherein said signature 
instruction causes a unique identifier to be pushed into a predefined area 
of storage upon execution of said true instructions at run-time. 
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ABSTRACT ' 

TRACING THE EXECUTION PATH OF A COMPUTER PROGRAM 

The invention relates to tracing the execution path of a computer 
program comprising at least one module including a plurality of 
instructions. At least one of these instructions is a branch instruction. 
Each branch instruction is identified and evaluated to be one of true and 
false. An evaluation of true results in a unique identifier being pushed 
into a predefined area of storage. This unique identifier is associated 
with the instructions executed as a result of an evaluation of true. 
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